Many conventional operating systems employ a registry that facilitates storage of information, for example, configuration information. Registry(ies) can serve as an information store for the operating system and for application(s) and service(s) running under the operating system. In one example, the registry stores a wide range of configuration settings ranging from boot parameters to user desktop settings. The registry can be stored as one or more configuration files stored on the storage system of a computer (e.g., persistent and/or non-persistent).
Application(s) can write (e.g., store) information in the registry upon installation. The registry is a hierarchically structured data store comprising subtrees of keys that reference per-computer and/or per-user data stores. A key can include data item(s) called value entries and can further include subkeys. In the registry structure, keys (and subkeys) can be thought of as analogous to directories with value entries being analogous to files. For example, the system registry can change on restart, logon and logoff.                For example, the registry can include the following major sections (e.g., subtrees):                    HKEY_Classes_Root—file associations and OLE information            HKEY_Current_User—preferences set for current user            HKEY_User—current user information for each user of the system            HKEY_Local_Machine—settings for hardware, operating system, and installed applications            HKEY_Current_Configuration—settings for the display and printers            HKEY_Dyn_Data—performance data                        
With ever increasing advances in operating system technology, simultaneously permitting both legacy and native applications to coexist has been a daunting task for the operating system, and more specifically, the system registry. For example, different versions of an application can store their configuration information in a common configuration data structure. In fact, different versions of an application typically store their configuration information at a same location within a common configuration data structure. Thus, a later installed version can overwrite existing configuration information for an earlier installed version. As a result, the earlier version is unlikely to run correctly (or at all) because its configuration information has been changed. Sometimes residual configuration exists in the common configuration data structure that can interfere with smooth performance of the later installed version.
Conventionally, compatibly and interoperability problems have occurred when a new version of an operating system (e.g., 32-bit) was introduced. To avoid these types of compatibility problems, the new 32-bit applications were instructed to store their configuration information in a different location (e.g., separate system registries) than the older 16-bit applications. In addition, they were directed to use different names for their application program interface(s) (“APIs”) and dynamic link libraries (“DLLs”). Although this conventional solution helped with compatibility and interoperability, it forced software developers to redirect large resources to software conversion rather to development of new or improved software. That is, 16-bit versions of software applications needed to be significantly modified to port to a 32-bit version.